…xception (#17512)

* [fix][tiered-storage] Don't cleanup data when offload met BadVersion
---

*Motivation*

There have two ways that will cause the offload data cleanup. One is met
offload conflict exception, and another is completeLedgerInfoForOffloaded
reaches max retry time and throws zookeeper exceptions.

We retry the zookeeper operation on connection loss exception. We should
be careful about this exception, because we may loss data if the metadata
update successfully.

When a MetaStore exception happens, we can not make sure the metadata update is
failed or not. Because we have a retry on the connection loss, it is
possible to get a BadVersion or other exception after retrying.

So we don't clean up the data if this happens.

*Modification*

- don't delete data if has meta store exception

* log error when skip deleting

* improve logs

(cherry picked from commit c2588ba)

…xception (#17512)

* [fix][tiered-storage] Don't cleanup data when offload met BadVersion
---

*Motivation*

There have two ways that will cause the offload data cleanup. One is met
offload conflict exception, and another is completeLedgerInfoForOffloaded
reaches max retry time and throws zookeeper exceptions.

We retry the zookeeper operation on connection loss exception. We should
be careful about this exception, because we may loss data if the metadata
update successfully.

When a MetaStore exception happens, we can not make sure the metadata update is
failed or not. Because we have a retry on the connection loss, it is
possible to get a BadVersion or other exception after retrying.

So we don't clean up the data if this happens.

*Modification*

- don't delete data if has meta store exception

* log error when skip deleting

* improve logs

(cherry picked from commit c2588ba)

…xception (apache#17512)

* [fix][tiered-storage] Don't cleanup data when offload met BadVersion
---

*Motivation*

There have two ways that will cause the offload data cleanup. One is met
offload conflict exception, and another is completeLedgerInfoForOffloaded
reaches max retry time and throws zookeeper exceptions.

We retry the zookeeper operation on connection loss exception. We should
be careful about this exception, because we may loss data if the metadata
update successfully.

When a MetaStore exception happens, we can not make sure the metadata update is
failed or not. Because we have a retry on the connection loss, it is
possible to get a BadVersion or other exception after retrying.

So we don't clean up the data if this happens.

*Modification*

- don't delete data if has meta store exception

* log error when skip deleting

* improve logs

(cherry picked from commit c2588ba)
(cherry picked from commit 917f997)

…xception (#17512)

* [fix][tiered-storage] Don't cleanup data when offload met BadVersion
---

*Motivation*

There have two ways that will cause the offload data cleanup. One is met
offload conflict exception, and another is completeLedgerInfoForOffloaded
reaches max retry time and throws zookeeper exceptions.

We retry the zookeeper operation on connection loss exception. We should
be careful about this exception, because we may loss data if the metadata
update successfully.

When a MetaStore exception happens, we can not make sure the metadata update is
failed or not. Because we have a retry on the connection loss, it is
possible to get a BadVersion or other exception after retrying.

So we don't clean up the data if this happens.

*Modification*

- don't delete data if has meta store exception

* log error when skip deleting

* improve logs

(cherry picked from commit c2588ba)

…xception (#17512)

* [fix][tiered-storage] Don't cleanup data when offload met BadVersion
---

*Motivation*

There have two ways that will cause the offload data cleanup. One is met
offload conflict exception, and another is completeLedgerInfoForOffloaded
reaches max retry time and throws zookeeper exceptions.

We retry the zookeeper operation on connection loss exception. We should
be careful about this exception, because we may loss data if the metadata
update successfully.

When a MetaStore exception happens, we can not make sure the metadata update is
failed or not. Because we have a retry on the connection loss, it is
possible to get a BadVersion or other exception after retrying.

So we don't clean up the data if this happens.

*Modification*

- don't delete data if has meta store exception

* log error when skip deleting

* improve logs

(cherry picked from commit c2588ba)

…xception (#17512)

* [fix][tiered-storage] Don't cleanup data when offload met BadVersion
---

*Motivation*

There have two ways that will cause the offload data cleanup. One is met
offload conflict exception, and another is completeLedgerInfoForOffloaded
reaches max retry time and throws zookeeper exceptions.

We retry the zookeeper operation on connection loss exception. We should
be careful about this exception, because we may loss data if the metadata
update successfully.

When a MetaStore exception happens, we can not make sure the metadata update is
failed or not. Because we have a retry on the connection loss, it is
possible to get a BadVersion or other exception after retrying.

So we don't clean up the data if this happens.

*Modification*

- don't delete data if has meta store exception

* log error when skip deleting

* improve logs

…xception

---

### Motivation

apache#17915 changes the fix apache#17512 which lead the offload data
is deleted when metadata store exception happened. Then the
ledger can not be read.

The logs shows
```
Failed to update offloaded metadata for the ledgerId 6197907, the offloaded data will not be cleaned up
```
But the ledger deleted. Then managed ledger failed to open it
```
Error opening ledger for reading at position 6197907:0
```

…xception

---

### Motivation

apache#17915 changes the fix apache#17512 which lead the offload data
is deleted when metadata store exception happened. Then the
ledger can not be read.

The logs shows
```
Failed to update offloaded metadata for the ledgerId 6197907, the offloaded data will not be cleaned up
```
But the ledger deleted. Then managed ledger failed to open it
```
Error opening ledger for reading at position 6197907:0
```